{"thread":{"id":"26902","subject":"[Q] Mark files for later commit?","startedAt":"2011-03-29T06:04:00Z","lastAt":"2011-03-29T12:15:12Z","messageCount":9,"participants":["Daniel Nyström","Junio C Hamano","Michael J Gruber","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164529","messageId":"AANLkTi=rPAQas3gvHJ+EFYTXP_YXuULQMk8o8pgkj=9T@mail.gmail.com","threadId":"26902","inReplyTo":null,"subject":"[Q] Mark files for later commit?","fromName":"Daniel Nyström","fromEmail":"daniel.nystrom@timeterminal.se","sentAt":"2011-03-29T06:04:00Z","receivedAt":"2011-03-29T06:04:00Z","isPatch":false,"sender":{"key":"daniel.nystrom@timeterminal.se","avatar":null},"body":"Hi folks!\n\nI just hit into an situation where a certain file contains a human\nwritten changelog, which is modified (not prepended) for each single\ncommit in the project, is being committed along with the actual patch.\n\nThis approach makes it very difficult to backport the commits, since\nit will always try patching the changelog file as well.\n\nThe changelog is only supposed to be committed at new releases, but is\nkept maintained continuously so stuff won't be forgotten.\n\nSo this makes me wonder, is there a way to mark certain files for\nbeing committed later on? Which does not automatically get added to\nthe staging area (on \"git commit -a\" or \"git add .\" and so on) unless\nit's specifically mentioned by \"git add\"?\n\nWe've discussed making it generated automatically, but that's not as\neasy as it may sound.\n\nHow would you like a git feature like described above, marking files\nfor later inclusion?\n\nThanks!\n--\nDaniel\n"},{"id":"164535","messageId":"7voc4uto9o.fsf@alter.siamese.dyndns.org","threadId":"26902","inReplyTo":"AANLkTi=rPAQas3gvHJ+EFYTXP_YXuULQMk8o8pgkj=9T@mail.gmail.com","subject":"Re: [Q] Mark files for later commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-29T06:49:07Z","receivedAt":"2011-03-29T06:49:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Nyström writes:\n\n> So this makes me wonder, is there a way to mark certain files for\n> being committed later on? Which does not automatically get added to\n> the staging area (on \"git commit -a\" or \"git add .\" and so on) unless\n> it's specifically mentioned by \"git add\"?\n>\n> We've discussed making it generated automatically, but that's not as\n> easy as it may sound.\n>\n> How would you like a git feature like described above, marking files\n> for later inclusion?\n\nThat does not sound like a feature but merely a source of confusion.\n\nSo far, \"commit -a\", \"add\", \"add .\" etc have _all_ been a way to tell git\nto add the current state of the content to the index. What is the point\nof making it more complex by letting the user say \"I am telling you to add\neverything in the working tree by explicitly saying 'git add .', but I do\nnot really mean it\"?\n\nIn the meantime, some misguided souls might suggest assume-unchanged, but\nthat is not guaranteed to work for this purpose, so ignore them. This is\nbecause assume-unchanged is a promise you make git that you will _not_\nchange the working tree files, and that promise implies a permission for\ngit to use blob object recorded in the index that corresponds to such a\npath instead of reading from the working tree files while doing certain\noperations (such as \"git diff\") if it is more convenient.\n"},{"id":"164542","messageId":"4D91858F.7030404@drmicha.warpmail.net","threadId":"26902","inReplyTo":"7voc4uto9o.fsf@alter.siamese.dyndns.org","subject":"Re: [Q] Mark files for later commit?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-29T07:09:03Z","receivedAt":"2011-03-29T07:09:03Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 29.03.2011 08:49:\n> Daniel Nyström writes:\n> \n>> So this makes me wonder, is there a way to mark certain files for\n>> being committed later on? Which does not automatically get added to\n>> the staging area (on \"git commit -a\" or \"git add .\" and so on) unless\n>> it's specifically mentioned by \"git add\"?\n>>\n>> We've discussed making it generated automatically, but that's not as\n>> easy as it may sound.\n>>\n>> How would you like a git feature like described above, marking files\n>> for later inclusion?\n> \n> That does not sound like a feature but merely a source of confusion.\n> \n> So far, \"commit -a\", \"add\", \"add .\" etc have _all_ been a way to tell git\n> to add the current state of the content to the index. What is the point\n> of making it more complex by letting the user say \"I am telling you to add\n> everything in the working tree by explicitly saying 'git add .', but I do\n> not really mean it\"?\n> \n> In the meantime, some misguided souls might suggest assume-unchanged, but\n> that is not guaranteed to work for this purpose, so ignore them. This is\n> because assume-unchanged is a promise you make git that you will _not_\n> change the working tree files, and that promise implies a permission for\n> git to use blob object recorded in the index that corresponds to such a\n> path instead of reading from the working tree files while doing certain\n> operations (such as \"git diff\") if it is more convenient.\n> \n\nWhile I've used assume-unchanged before, it really is a great foot-gun\n(to shoot yourself into...) to be used only when circumstances force you.\n\nIn your case, if you really can't use shortlog or the like, a \"light\"\nway of generating a changelog might be using notes. Attach changelog\nnotes to each commit (maybe in refs/notes/changelog rather than the\nstandard). Then, when you need to create the changelog between vX and\nvY, you can do\n\ngit log --pretty=\"%N%n\" vX..vY\n\n(and go wild on the pretty format, of course). Note that you can share\nnotes when you set up refspecs etc in a push/pull based workflow. (I'm\nnot sure how well we support merging/pulling notes refs yet.) This does\nnot work well in a patch/e-mail-based workflow.\n\nMichael\n"},{"id":"164546","messageId":"201103290938.41528.johan@herland.net","threadId":"26902","inReplyTo":"4D91858F.7030404@drmicha.warpmail.net","subject":"Re: [Q] Mark files for later commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2011-03-29T07:38:41Z","receivedAt":"2011-03-29T07:38:41Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 29 March 2011, Michael J Gruber wrote:\n> Note that you can share\n> notes when you set up refspecs etc in a push/pull based workflow. (I'm\n> not sure how well we support merging/pulling notes refs yet.)\n\nSince v1.7.4, you can use \"git notes merge\" for merging notes ref. It's not \nyet integrated with \"pull\", though, so typically you want to fetch it to a \ndifferent ref name, and then manually \"git notes merge\" that into the \noriginal notes ref.\n\nE.g. if you want to sync \"refs/notes/foo\" with remote \"bob\", you can \"git \nfetch bob refs/notes/foo:refs/notes/bobs_foo\", and then\nmerge them with \"git notes --ref=foo merge bobs_foo\".\n\n> This does not work well in a patch/e-mail-based workflow.\n\n...although there have been mailing list discussions on getting notes added \nto \"git format-patch\" output (after the \"---\"), and then picked up again by \n\"git am\".\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"164547","messageId":"4D918E2E.4000206@drmicha.warpmail.net","threadId":"26902","inReplyTo":"201103290938.41528.johan@herland.net","subject":"Re: [Q] Mark files for later commit?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-29T07:45:50Z","receivedAt":"2011-03-29T07:45:50Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johan Herland venit, vidit, dixit 29.03.2011 09:38:\n> On Tuesday 29 March 2011, Michael J Gruber wrote:\n>> Note that you can share\n>> notes when you set up refspecs etc in a push/pull based workflow. (I'm\n>> not sure how well we support merging/pulling notes refs yet.)\n> \n> Since v1.7.4, you can use \"git notes merge\" for merging notes ref. It's not \n> yet integrated with \"pull\", though, so typically you want to fetch it to a \n> different ref name, and then manually \"git notes merge\" that into the \n> original notes ref.\n\nYes, but what I meant with \"well\" was: If I merge regular branches, do\nthe notes get merged automatically? And the answer is \"no\", and as you\nexplain above, \"git notes merge\" copes with that (and with merging notes\nfor the same commit).\n\n> E.g. if you want to sync \"refs/notes/foo\" with remote \"bob\", you can \"git \n> fetch bob refs/notes/foo:refs/notes/bobs_foo\", and then\n> merge them with \"git notes --ref=foo merge bobs_foo\".\n\nLonging for that refs/ layout overhaul...\n\n>> This does not work well in a patch/e-mail-based workflow.\n> \n> ...although there have been mailing list discussions on getting notes added \n> to \"git format-patch\" output (after the \"---\"), and then picked up again by \n> \"git am\".\n\nSo, here my \"not well\" was even overly positive ;)\n\nMichael\n"},{"id":"164548","messageId":"7v8vvytldk.fsf@alter.siamese.dyndns.org","threadId":"26902","inReplyTo":"7voc4uto9o.fsf@alter.siamese.dyndns.org","subject":"Re: [Q] Mark files for later commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-29T07:51:35Z","receivedAt":"2011-03-29T07:51:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Daniel Nyström writes:\n>\n>> So this makes me wonder, is there a way to mark certain files for\n>> being committed later on? Which does not automatically get added to\n>> the staging area (on \"git commit -a\" or \"git add .\" and so on) unless\n>> it's specifically mentioned by \"git add\"?\n>>\n>> We've discussed making it generated automatically, but that's not as\n>> easy as it may sound.\n>>\n>> How would you like a git feature like described above, marking files\n>> for later inclusion?\n>\n> That does not sound like a feature but merely a source of confusion.\n\nLet's step back a bit, as I think \"mark them not to be added\" is a classic\nXY problem.\n\nFirst let's concentrate on this part: \"a certain file contains a human\nwritten changelog, which is modified (not prepended) for each single\ncommit in the project, is being committed along with the actual patch.\"\n\nDoesn't that sound quite similar to our release notes?\n\nSo far, I've been updating the file after topics graduate to the 'master'\nbranch, but there is no fundamental reason not to make it a responsibility\nof the patch contributors to add an entry to the release notes when they\nmake their changes to the system. Then when the topics graduate, the\nentry that describes the topic will be automatically merged into the\nrelease notes of the 'master' branch.\n\nWhat will happen if we made that the convention of our project? For one\nthing, I don't have to spend time on coming up with a concise and clear\ndescription of the topics (the contributor that worked on the topic should\nbe better equipped to describe it than I am). People may make their own\nentries in the single release notes file in various places (by convention,\nthe entries are sorted by the name of the command the change affects,\nexcept for the ones that have system-wide effects that are described at\nthe top), and merging them might produce many conflicts, though.\n\nBut what choice would I have? Obviously I shouldn't be punting on the\nmerges, taking one side of the release notes file as the merge result\nusing \"-s ours\" or other silly magic and discarding the valuable input\nfrom contributors. I _do_ want all the release notes entries from all\ntopics. Merging such a conflict-heavy file and keeping it maintained\nproperly is an important part of the job (iow, \"suck it up\").\n\nI suspect that using the \"union\" merge attribute may be a possibility in\nthis case; even though the release notes is not an \"append only\" file, it\nis an \"insert only\" file, and it is a very good candidate for the union\nmerge driver.\n\nNow let's look at this part: \"The changelog is only supposed to be\ncommitted at new releases, but is kept maintained continuously so stuff\nwon't be forgotten.\"\n\nYou are willing to leave your changes uncommitted in the working tree, and\nnot committing it until the release (perhaps using your Y solution that\nlets you mark it not to be committed without --force option), is perfectly\nOk by you. You are not getting any accident protection benefit from your\nSCM until the next release point and the intermediate changes between\nreleases you make to this file are not version controlled.\n\nIf that is the case, then probably you shouldn't be even updating the\n\"changelog\" file constantly to begin with. Instead, how about creating a\nseparate \"changelog+\" file that is not tracked, and keep its contents\nmaintained continuously so stuff won't be forgotten? When the time to\nrelease comes, you can \"mv changelog changelog\", and commit it.\n\nThat would still require you to find a relevant entry in changelog+ and\nmodify the true changelog file if you cherry pick a particular change to\nan older maintenance track and make a release out of it. Keeping the\nentries in the changelog, and cherry picking the changes together with the\nassociated entries will probably reduce that \"remembering\" mental burden,\nwhile it may require trivial conflict resolutions in the file that can be\nhelped with the union merge driver.\n\nJust a few cents.\n"},{"id":"164552","messageId":"AANLkTik33jiKipcv8d8tY_FXa2nE0BtBdi9vro0gkdQc@mail.gmail.com","threadId":"26902","inReplyTo":"7v8vvytldk.fsf@alter.siamese.dyndns.org","subject":"Re: [Q] Mark files for later commit?","fromName":"Daniel Nyström","fromEmail":"daniel.nystrom@timeterminal.se","sentAt":"2011-03-29T09:18:46Z","receivedAt":"2011-03-29T09:18:46Z","isPatch":false,"sender":{"key":"daniel.nystrom@timeterminal.se","avatar":null},"body":"Den 29 mars 2011 09:51 skrev Junio C Hamano :\n>> Daniel Nyström writes:\n>>> How would you like a git feature like described above, marking files\n>>> for later inclusion?\n>>\n>> That does not sound like a feature but merely a source of confusion.\n>\n> If that is the case, then probably you shouldn't be even updating the\n> \"changelog\" file constantly to begin with.  Instead, how about creating a\n> separate \"changelog+\" file that is not tracked, and keep its contents\n> maintained continuously so stuff won't be forgotten?  When the time to\n> release comes, you can \"mv changelog changelog\", and commit it.\n\nIf we ignore this particular case, how would a \"git hold ...\" feature do?\n--\n$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n#\n#\tmodified: package/qt/qt.mk\n#\n# Changed but on hold:\n# (use \"git add --holds ...\" to update what will be committed)\n#\n#\tmodified: CHANGES\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n--\nWould there be other use-cases?\n"},{"id":"164563","messageId":"4D91CA31.20908@drmicha.warpmail.net","threadId":"26902","inReplyTo":"AANLkTik33jiKipcv8d8tY_FXa2nE0BtBdi9vro0gkdQc@mail.gmail.com","subject":"Re: [Q] Mark files for later commit?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-29T12:01:53Z","receivedAt":"2011-03-29T12:01:53Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Daniel Nyström venit, vidit, dixit 29.03.2011 11:18:\n> Den 29 mars 2011 09:51 skrev Junio C Hamano :\n>>> Daniel Nyström writes:\n>>>> How would you like a git feature like described above, marking files\n>>>> for later inclusion?\n>>>\n>>> That does not sound like a feature but merely a source of confusion.\n>>\n>> If that is the case, then probably you shouldn't be even updating the\n>> \"changelog\" file constantly to begin with. Instead, how about creating a\n>> separate \"changelog+\" file that is not tracked, and keep its contents\n>> maintained continuously so stuff won't be forgotten? When the time to\n>> release comes, you can \"mv changelog changelog\", and commit it.\n> \n> If we ignore this particular case, how would a \"git hold ...\" feature do?\n> --\n> $ git status\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> # (use \"git checkout -- ...\" to discard changes in working directory)\n> #\n> #\tmodified: package/qt/qt.mk\n> #\n> # Changed but on hold:\n> # (use \"git add --holds ...\" to update what will be committed)\n> #\n> #\tmodified: CHANGES\n> #\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> --\n> Would there be other use-cases?\n\nAs Junio pointed out, your \"hold file\" (ChangeLog+) is really not\nversioned (tracked) at all, so it has no place in the worktree.\nOtherwise you'll have constant nagging during the release cycle one way\nor the other, if you want git to remind you of the files on hold. If you\ndon't need the reminder, git does not need to know about the file.\nSimply store it somewhere else (such as in .git/description if you don't\nuse that, or under .git/info/).\n\nMichael\n"},{"id":"164565","messageId":"AANLkTiktzbFUtRURaGxxm+dgG+KSOd6cbVQ49x8qK6EZ@mail.gmail.com","threadId":"26902","inReplyTo":"4D91CA31.20908@drmicha.warpmail.net","subject":"Re: [Q] Mark files for later commit?","fromName":"Daniel Nyström","fromEmail":"daniel.nystrom@timeterminal.se","sentAt":"2011-03-29T12:15:12Z","receivedAt":"2011-03-29T12:15:12Z","isPatch":false,"sender":{"key":"daniel.nystrom@timeterminal.se","avatar":null},"body":"Den 29 mars 2011 14:01 skrev Michael J Gruber :\n> Daniel Nyström venit, vidit, dixit 29.03.2011 11:18:\n>> Den 29 mars 2011 09:51 skrev Junio C Hamano :\n>>>> Daniel Nyström writes:\n>>>>> How would you like a git feature like described above, marking files\n>>>>> for later inclusion?\n>>>>\n>>>> That does not sound like a feature but merely a source of confusion.\n>>>\n>>> If that is the case, then probably you shouldn't be even updating the\n>>> \"changelog\" file constantly to begin with.  Instead, how about creating a\n>>> separate \"changelog+\" file that is not tracked, and keep its contents\n>>> maintained continuously so stuff won't be forgotten?  When the time to\n>>> release comes, you can \"mv changelog changelog\", and commit it.\n>>\n>> If we ignore this particular case, how would a \"git hold ...\" feature do?\n>\n> As Junio pointed out, your \"hold file\" (ChangeLog+) is really not\n> versioned (tracked) at all, so it has no place in the worktree.\n> Otherwise you'll have constant nagging during the release cycle one way\n> or the other, if you want git to remind you of the files on hold. If you\n> don't need the reminder, git does not need to know about the file.\n> Simply store it somewhere else (such as in .git/description if you don't\n> use that, or under .git/info/).\n\nGood points, indeed. But untracked files will be tracked on \"git add\n.\" which files on hold won't.\n\nBut I agree, the \"hold\" feature requires a better motivation and more\nactual use cases. I thought it may catch some interests on the list.\n"}]}